Subject: FW: Searching for non-LU resources

From: Matthew Finlayson <[email-masked]>
Date: Tue, 15 Aug 95 10:23:00 BST

This is Data Connection's initial feedback on the Resource Registration
proposal which Ron Sanders has submitted for discussion at the AIW.

The bottom-line is that

 -  We think that the functionality the proposal is intending to provide
   would be extremely useful and would help make APPN/APPC easier to
   use (and more popular).

 -  We worry that the proposal as it stands will not provide a migration
   path for a network of non-upgraded nodes.

 -  We think that the DS architecture makes it unsuitable for a lot of the
   additional function the proposal introduces.

These comments are explained in more detail below.

Matthew.

General comments:
=================

One of our main worries is with the impact of this proposal on a network of
current-level NNs.  Our belief is that to make use of the current proposal
fully, all the NN servers in the network would have to be upgraded.  The 
main
reasons for this are as follows:

 -  The proposal suggests that the locate buffer size be increased to 32Kb.
   We feel that this is far too large (and I will discuss this later) but
   it will also cause interoperability problems.  If an NN tries to send a
   current-level NN more data than 1024 bytes (the current limit) then the
   receiving NN will not accept it (and may well bring down CP-CP sessions 
due
   to the protocol violation).  This would cause particular problems if the
   current-level NN was a route to a CDS (which could be expected to
   return large amounts of data).

 -  Much of the functionality provided by the proposal relies on multiple
   (positive) responses to the "Locate/Find(CV3E)".  Current-level NNs will
   react to the second positive reply not by forwarding it on but will
   generate an alert to indicate a configuration error in the network (with
   sense code 10100001).

Following on from this, we have a fundamental worry about the way the
proposal clashes with the way the DS algorithms have been designed to work.
The introduction of the concept of multiple replies/multiple resources
with the same name/wildcard searches.  The algorithms have been
optimized to expect only single positive replies.  Similarly the caching
mechanisms will be useless with new proposal.  It seems that while making
use of the DS mechanism for the proposal appears to leverage function, in
actual fact much of it is given up.

We also have a general worry about the proposal's interaction with CDS and
Border Node.

 -  The proposal assumes that all resources are required to be registered
   with a CDS.  Otherwise searching the CDS does not help, since you will
   have to carry out a broadcast search in any case to discover any
   unregistered resources.

 -  How will the proposal interoperate with BNs?  Will all LOCATE requests
   be fanned out to all attached networks, or will some filtering take
   place?

Detailed comments:
==================

These are more detailed feedback on the proposal.  The comments on the flows
are included for completeness, although Ron is already aware and agrees with 
them.

> o ANAME Server.
>
> The ANAME client and server applications are part of the APPC Application 
Suite
> (ASUITE) from IBM.  Specifications for the ASUITE programs, including 
ANAME,
> are available from IBM at no cost.  Source code for the programs is 
available
> for a license fee.
>
> ANAME is an application that addresses many of the requirements that 
motivate
> this document.  It consists of CPI-C like services that can be called by 
client
> applications to register with the remote directory server and to search 
for
> resources.  IBM has announced the availability of ANAME on most of its 
major
> platforms.  However, we have a number of concerns about ANAME as a 
permanent
> solution to the application directory requirements:
>
> 1) Although the specifications have been made available, they have not 
been
>    submitted to the AIW or CIW as a proposed architecture.

They could be submitted - as you say IBM has already made the specifications
available.

> 2) The application-level approach does not take advantage of any of the 
APPN
>    directory services functionality.  APPN directory services represents a
>    significant set of functions: it is a distributed non-replicated data 
base,
>    with each node aware only of those resources relevant to its operation;
>    there is no single point of failure; scalability is built in with the
>    central directory server; partitioning is built in with border node;
>    broadcast searches are performed automatically to locate unknown 
resources;
>    directed searches are performed to verify that cached resource 
information
>    is still valid.  More could be said, however the point is that there 
are
>    many advanced functions already implemented in directory services that 
will
>    likely have to be re-invented eventually in a parallel 
application-level
>    solution like ANAME.

That's true but providing this sort of function at an application level has
several attractions as it

 - requires no changes to existing nodes (a better migration path)

 - can be used by LEN nodes as well as APPN nodes

 - will general cost less to implement, both in terms of development
   costs and time to market.

> 3) The ANAME service reduces the amount of coordinated system definition 
needed
>    for APPC applications, but does not eliminate it.  Network 
administrators
>    must still deal with maintaining the definitions required to access the
>    ANAME server.
>

This problem could be solved (for example by using the Discovery 
architecture,
or by adding the information to the topology database as for CDS).

> o New CV 3E must be added and used in place of CV 3D.

Current NNs check to verify that a "CV3D" is present (and if not then
generate the sense code 1014003D).  A dummy "CV3D" will need to be supplied
with the "CV3E" in all flows to avoid this.

>     Summary Flows:
>
>     Service Resource Registration example:
>
>     Service TP1        Encp1                        NN1 
                CDS
 -----------------------------------------------------------------------
>     CMADDSRV ---------->
>                        | Register(GDS 12C3(CV3C,CV3E))
>                        +---------------------------->
>                                                     |Register(GDS 
12C3(CV3C,CV3E))
>                                                     +-------------------->

The Register request to the CDS will include a Locate GDS variable.

>                                                            +Reply        |
>                                                     <--------------------+
>                               +Reply                |
>                        <----------------------------+
>             RC=OK      |
>     <------------------+
>     .
>     .
>     .
>

This is not exactly the way registration will take place.  A NN does not 
wait
until it has successfully registered with the CDS before positively replying
to the EN.  Indeed it would also be prohibitively difficult to require the 
EN
to wait until the NN has replied before returning the CMADDSRV verb - for
example, what should happen if the EN has not yet established CP-CP 
sessions?

>
>
>     Service Connection (with CDS, no wildcards) example:
>
>     Client TP2        Encp1            NN1             CDS      ENCP2 
   TP1
 ------------------------------------------------------------------------
>     CMINIT
>     CMCNSRV ---------->
>                       | Locate/Cdinit/Find(CV3E)
>                       +--------------->
>                                       | Locate/Cdinit/Find(CV3E)
>                                       +---------------->

The CDS will then send on a directed search to ENCP2 in order to retrieve
its tail-vectors.

>                                       +Reply(CV3C,CV3E)|
>                                       <----------------+
>                      +Reply(CV3C,CV3E)|
>                        <--------------+
>                        |    BIND
>                        +---------------------------------------->
>                                               +RSP(BIND)        |
>                        <----------------------------------------+
>             RC=OK      |
>     <------------------+
>     CMSEND
>     CMRCV                     Attach TP1, data
>     +-------------------------------------------------------------------->
>     .
>     .
>     .
>
>
>
>     Service Connection (without CDS, wildcards in use) example:
>
>     Client TP2        Encp1            NN1             NN2      ENCP2 
   TP1
 ------------------------------------------------------------------------
>     CMINIT
>     CMCNSRV ---------->
>                       | Locate/Cdinit/Find(CV3E)
>                       +--------------->
>                       | Locate/Cdinit/Find(CV3E)
>                       +--------------------------------->

This flow suggests that ENCP1 has CP-CP sessions to multiple NNs. 
 Presumably
you mean that NN1 will forward the "Locate/Cdinit/Find(CV3E)" on to NN2?

>
>                      +Reply(CV3C,CV3E)|
>                        <--------------+
>                        |
>                        |               +Reply(CV3C,CV3E)|
>                        | <------------------------------+
>                        | Discarded
>                        |
>                        |    BIND
>                        +---------------------------------------->
>                                               +RSP(BIND)        |
>                        <----------------------------------------+
>             RC=OK      |
>     <------------------+
>     CMSEND
>     CMRCV                     Attach TP1, data
>     +-------------------------------------------------------------------->
>     .
>     .
>     .
>
>
>
> Query Service (with CDS, wildcards in use) example.  Two resouces located:
>
>     Client TP2        Encp1            NN1 
                              CDS
 ------------------------------------------------------------------------
>     CMQRYSRV ---------->
>                        | Locate/Find(CV3E)
>                        +-------------->
>                                       | Locate/Find(CV3E)
 +----------------------------------->
>                                           +Reply((CV3C,CV3E),(CV3C,CV3E)) 
|
 <-----------------------------------+

Again, the CDS will then have to carry out (multiple?) directed searches.

>                   +Reply((CV3C,CV3E), |
>                          (CV3C,CV3E)) |
>                        <--------------+
>         RC=OK          |
>         Service1, luX  |
>         Service2, luY  |
>     <------------------+
>     .
>     .
>     .
>
>
> Query Service (without CDS, wildcards in use) example.  Two resource 
located by
> NN1, one resource located by NN2, all three resources returned to client 
TP:
>     Client TP2        Encp1                 NN1 
                        NN2
 -----------------------------------------------------------------------
>     CMQRYSRV ---------->
>                        | Locate/Find(CV3E)
>                        +-------------------->
>                        | Locate/Find(CV3E)
>                        +------------------------------------------------>

Again, the second Locate will be sent via NN1 ...

>
>                         +Reply((CV3C,CV3E), |
>                                (CV3C,CV3E)) |
>                        <--------------------+
>
>                                                       +Reply(CV3C,CV3E) |
>                        <------------------------------------------------+

and the response will returned via NN1.

>         RC=OK          |
>         Service1, luX  |
>         Service2, luY  |
>         Service3, luY  |
>     <------------------+
>     .
>     .
>     .

>  o In positive locate replies a CV 3C of type 0x00F3 (LU) will always be 
paired
>    with and precede the CV 3E.

Replacing the "CV3D" of type LU with a "CV3C" will prevent back-level
compatibility.

>  o The network identifier associated with the resource name is the net ID 
of the
>    Owning LU as identified in the CV 3C preceding the CV 3E.
>
>  o New fields in the data base are only relevant if a CV 3E is received on
>    resource registration.

Does that mean that if an EN does not register including a "CV3E" then the
NN will not allow it to make use of the new function?

>  o Resource Registration 12C3 to include CV 3E instead of 3D.
>
>  o Service Resource Registration requests will unconditionally result in
>    registration of the resource with the CDS.  This is to optimize locate 
flows
>    and minimize the impact of query locates.

At the moment, registration of resources with CDS is optional (and is
specified on the registration request with the NN).  Are you suggesting that
we surrender this capability?

> o The ability to detect support for Service Resource Registration must be
>   provided.  Three options exist that will provide this function:
>
> 1) Modify session services REQUEST_CP_CAP_TP to set a new (to be defined) 
bit
>    in CP Capabilities GDS (12C1) to indicate that service resources are
>    supported.  This option will have the least impact on existing
>    implementations.

Since with 1015 the EN receives the CP Capabilities of the NN before sending
its own, it would be conceivable that an EN supporting the proposed function
could check whether the adjacent NN also supported it, and if not request
that it handle roadcast searches itself on its own Capabilities GDS.

This would mean that the following change would not be needed.

>  o DS must not send DEACTIVATE_CP_CP_SESSION signal to SS when 1014003D is
>    indicated as the reason for registration or locate failure.  This 
change can
>    easily be PTF'ed into existing releases.  The alternative to this is to
>    include a dummy CV 3D that would let registration and locate requests 
either
>    complete with a -reply or permit pass-through to a CDS that supported 
the
>    service resource functionality.

> o Expand RECEIVE_NETWORK_SEARCH_TP buffer size to 32000 to accommodate 
query
>    service replies.

Aside from the interoperability problems I discussed earlier, this would
place a tremendous burden on NNs.  To optimise performance and guarantee
delivery an NN is required to preallocate space for all the LOCATE requests
that it is handling.  Increasing the size of the buffer required to such an
extent would cripple the LOCATE processing capabilities of the NN.

> o Query Locate requests will always result in a directed search to the CDS 
if a
>   CDS exists in the network.  Local directory searches will be bypassed. 
 Only
>   if a CDS does not exist in the network will a broadcast search be 
initiated.

Or indeed if the CDS does not know about the resource being searched for?

> o Resources returned in query Locate replies will always be propagated to
>   presentation services in the order that individual replies were 
received.
>   This permits the application TP to make assumptions as to the "best" 
resource
>   to use.

The "best" resource to use cannot be determined without route computation.
(For example, some resources may not be reachable with a particular COS.)

> UNRESOLVED ISSUES:
>
> The use of a CDS, as represented in this proposal, is a mixed blessing. 
 When
> wildcard broadcast searches are used, positive replies will be returned at
> different rates depending on the distance between the origin resource and
> destination resource and the loading on the destination resources at any 
point
> in time.  With broadcast searches it is possible to make a reasonable
> assumption that the first reply is the best reply and contains the best
> resource.
>
> The use of a CDS minimizes the volume of network traffic that could result 
from
> broadcast searches.  However, when wild card locates are employed and the 
CDS
> knows about all the resources in the network, it will most likely reply to 
a
> CMQRYSRV or CMCNSRV with equal speed for each target resource located -
> regardless of how far away from the origin resource it is.  This makes it
> difficult to determine which resource is the best resource to use.

This is not entirely accurate.  As I mentioned earlier, when a CDS is 
queried
for a resource, it will then perform a directed search to that resource (and
the time of this directed search may well vary if a resource is further 
away).

==============================================================
Matthew Finlayson                  Data Connection Limited
([email-masked])                 Telephone: +44 181 366 1177
                                   Fax:       +44 181 367 8501
==============================================================

---

From: "Jim Fletcher ((919) 254-5929)" <[email-masked]>
Date: Tue, 15 Aug 95 08:11:22 EDT

Ref:  Your note of Tue, 15 Aug 1995 05:34:35 -0400

I too agree that the functions provided by the proposal are needed, but
I would raise concern with using ANAME as the solution. ANAME operates at
a layer above APPN and as such is not really an integrated solution. Aname
requires additional sessions in order to provide its services. This
places greater overhead on the network and its related products since
sessions are either constantly being created and discarded simply to obtain
a service (I equate this to the SNASVCMG session overhead).

While I agree that APPN DS is "broken" in various ways, we should attempt to
provide the new functions on the existing structure.

I also strongly agree that we need an implementation path that permits
migration to the new functions, and not any kind of forklift upgrade.

I hope we can make this work ... I see significant value-add to APPN as
we added these services.